These are interesting ideas. I'll look into them once I'm satisfied the
control hull is good enough. I'm pretty sure it is, but I'm going to wait a
few days on that and see if there are any other opinions. I'm sort of
abusing the bicubic_patch by treating the points of the control hull as if
they were controlling bezier vectors attached to the nearest data point.
There may well be better forms of abuse than the one I've chosen (doing it
right would entail a lot of cubic expressions and I think slow things down
to a huge amount-- and not be anywhere near as much fun).

I am confused about the translation you are proposing-- I don't think that,
for instance,  (iX+dX*C) can be subtracted out from all the points in the
bicubic. Wouldn't that imply that  dX*C + 0.5 = dX*(C + 0.5) which I think
breaks the law of distribution of multiplication over addition?

I think your corrections to the expressions defining dX and dZ are right,
and I had them wrong.

I've gaining a better understanding of the uv_mapping problem. What is
happening is the image is being mapped correctly to the entire patchwork,
which includes the pseudodata rows and columns. So the margins of the image
are lost when the patchwork is clipped to its final size, and the image has
also undergone the equivalent of a scale <1+2*dX, 1, 1+2*dZ>. I'm at a loss
about how to correct for these problems. That is, unless I turn the
uv_mapping statement into something really ugly.


--
Will Woodhull
Thornhenge, SW Oregon, USA
willl.at.thornhenge.net



"Tor Olav Kristensen" <tor_olav_kCURLYAhotmail.com> wrote in message
news:Xns### [at] 204213191226...
> Tor Olav Kristensen <tor_olav_kCURLYAhotmail.com> wrote in
> news:Xns### [at] 204213191226:
>
> ...
>
> > Have a look at the code below code. (It does the same
> > as yours but calculates iX + dX*C and iZ + dZ*R only
> > once in each loop instead of 16 times.)
> >
> >
> > // This first line should be placed outside the loops
> > #local vXYZ = <dX, dY, dZ>;
> > .
> > <snip>
> > .
> >   bicubic_patch {
> >     type 1  flatness 0 u_steps 3 v_steps 3
> > .
> > <snip>
> > .
> >     <0.0, A[R  ][C  ][Y]                 , 0.0>*vXYZ
> >     <0.5, A[R  ][C  ][Y] + A[R  ][C  ][X], 0.0>*vXYZ
> > .
> > <snip>
> > .
> >     <0.5, A[R+1][C+1][Y] - A[R+1][C+1][X], 1.0>*vXYZ
> >     <1.0, A[R+1][C+1][Y]                 , 1.0>*vXYZ
> >     translate <iX + dX*C, 0, iZ + dZ*R>
> >   }
>
>
> I forgot to mention that you can probably move the
> vXYZ vector into a scale statement at the end to save
> further calculations. Like this:
>
>
>   bicubic_patch {
>     type 1  flatness 0 u_steps 3 v_steps 3
> .
> <snip>
> .
>     <0.0, A[R  ][C  ][Y]                 , 0.0>
>     <0.5, A[R  ][C  ][Y] + A[R  ][C  ][X], 0.0>
> .
> <snip>
> .
>     <0.5, A[R+1][C+1][Y] - A[R+1][C+1][X], 1.0>
>     <1.0, A[R+1][C+1][Y]                 , 1.0>
>     scale vXYZ
>     translate <iX + dX*C, 0, iZ + dZ*R>
>   }
>
>
> Tor Olav

Post a reply to this message